Fix task host launch regressions from apphost support#13325
Merged
YuliiaKovalova merged 4 commits intomainfrom Mar 4, 2026
Merged
Fix task host launch regressions from apphost support#13325YuliiaKovalova merged 4 commits intomainfrom
YuliiaKovalova merged 4 commits intomainfrom
Conversation
Three bugs introduced by c8011cb (Add App Host Support for MSBuild): 1. CLR2 task host (MSBuildTaskHost.exe) broken on .NET Core MSBuild: ResolveExecutableName only recognized MSBuild.exe as a native executable. Any other .exe (like MSBuildTaskHost.exe) was incorrectly routed through dotnet.exe, which cannot host .NET Framework 3.5 executables. Fix: detect native executables by checking for .dll extension instead of matching a specific filename. Only .dll files need dotnet.exe as host. 2. .NET task host fallback broken when DotnetHostPath is null: ResolveAppHostOrFallback created NodeLaunchData with null MSBuildLocation when apphost was missing and TaskHostParameters.DotnetHostPath was not set. Fix: auto-discover dotnet host via CurrentHost.GetCurrentHost() when the parameter is null. 3. MSB4216 error shows wrong executable path for .NET task hosts: LogErrorUnableToCreateTaskHost had a #if NETFRAMEWORK guard that prevented it from using the correct .NET path when running on .NET Core. It always showed the non-.NET path (MSBuild.exe) regardless of task host type. Fix: check HandshakeOptions.NET on all runtimes, not just .NET Framework. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes three regressions introduced by PR #13175 (app host support for MSBuild), all related to incorrect task host process launching behavior.
Changes:
NodeLauncher.cs: Broadens the "native executable" detection from onlyMSBuild.exeto all non-.dllfiles, soMSBuildTaskHost.exeand other.exelaunchers are run directly instead of being incorrectly routed throughdotnet.exe.NodeProviderOutOfProcTaskHost.cs: Auto-discovers the dotnet host path viaCurrentHost.GetCurrentHost()whenTaskHostParameters.DotnetHostPathis null, preventing a silent null-MSBuildLocationfailure in the fallback code path.TaskHostTask.cs: Removes the#if NETFRAMEWORKguard from the.NETruntime path resolution inLogErrorUnableToCreateTaskHost, so the correct.NETtask host path (app host) is shown in error messages on .NET Core builds too.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/Build/BackEnd/Components/Communications/NodeLauncher.cs |
Fixes CLR2 task host (MSBuildTaskHost.exe) being incorrectly launched via dotnet.exe by switching from name-based to extension-based native/managed classification. |
src/Build/BackEnd/Components/Communications/NodeProviderOutOfProcTaskHost.cs |
Adds auto-discovery of the dotnet host path when null, preventing a silent build failure in the app-host-absent fallback path. |
src/Build/Instance/TaskFactories/TaskHostTask.cs |
Removes the #if NETFRAMEWORK guard so that .NET task host error messages always show the correct executable path on all runtimes. |
Add two e2e tests to NetTaskHost_E2E_Tests covering the CLR2 task host scenario that was broken by the apphost changes: 1. CLR2TaskHost_Net35ProjectWithResources_BuildSucceeds: Builds a .NET 3.5 WinForms project with embedded resources, which triggers GenerateResource via MSBuildTaskHost.exe (CLR2 runtime). Verifies no MSB4216 errors occur. 2. CLR2TaskHost_FrameworkTaskWithTaskHostFactory_UsesCorrectProcess: Runs the ExampleFrameworkTask through TaskHostFactory, verifying the Framework task host launches correctly without MSB4216 errors. Both tests validate the fix in NodeLauncher.ResolveExecutableName that detects native executables by .dll extension rather than matching a specific filename, preventing MSBuildTaskHost.exe from being incorrectly routed through dotnet.exe. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
YuliiaKovalova
added a commit
to dotnet/dotnet
that referenced
this pull request
Mar 4, 2026
Apply fixes from dotnet/msbuild#13325: - ResolveExecutableName: detect native executables by .dll extension check - ResolveNodeLaunchConfiguration: restore CLR2 branch with proper handshake - ResolveAppHostOrFallback: auto-discover dotnet host path when not provided - LogErrorUnableToCreateTaskHost: fix for .NET host context Experiment to verify if these fixes resolve the VSTestTask failure in offline source-build. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
JanProvaznik
approved these changes
Mar 4, 2026
Member
JanProvaznik
left a comment
JanProvaznik
left a comment
There was a problem hiding this comment.
ok with the last commit I trust it
Member
|
@rainersigwald also ptal |
rainersigwald
approved these changes
Mar 4, 2026
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
This was referenced Mar 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes three regressions introduced by #13175 (Add App Host Support for MSBuild, commit c8011cb).
Bug 1: CLR2 task host (MSBuildTaskHost.exe) broken - VS build failures
Root cause:
NodeLauncher.ResolveExecutableNameonly recognizedMSBuild.exe(Constants.MSBuildExecutableName) as a native executable. Any other.exe- includingMSBuildTaskHost.exe- was treated as a managed assembly and routed throughdotnet.exe. SinceMSBuildTaskHost.exeis a standalone .NET Framework 3.5 executable,dotnet.execannot host it.Bug 2: .NET task host fallback broken when
DotnetHostPathis nullSymptom:
MSB4216: ... the required executable "...\sdk\11.0.100-ci\MSBuild.exe" exists and can be run- in CI where the apphost hasn't been created yet.Root cause:
ResolveAppHostOrFallbackcorrectly detects the missing apphost and tries to fall back todotnet MSBuild.dll, butTaskHostParameters.DotnetHostPathis null (not populated byAssemblyTaskFactory). This producesNodeLaunchData(null, ...)which silently fails inCreateNode.Bug 3: MSB4216 error shows wrong executable path for .NET task hosts
Root cause:
LogErrorUnableToCreateTaskHostinTaskHostTask.cshas a#if NETFRAMEWORKguard around the .NET task host path resolution. On .NET Core (the common case), it always falls through toGetMSBuildExecutablePathForNonNETRuntimeswhich returns the non-.NET path (MSBuild.exe), even for.NETtask host failures.